Assassins - Ultimate CD Games Collection 1/Assassins - Ultimate CD Games Collection (1994)(Weird Science)(Track 1 of 2)[!][Amiga-CD32-CDTV][CDD5332].iso/instructions/misc/dungeon

Text File | 1991-02-17 | 14KB | 320 lines

              Portable (More or Less) Dungeon

This is the old standby Dungeon game that was distributed on countless
DECUS tapes, in a form that only ran on certain DEC computers,
portabilized for the world for of Unix and MS-DOS. AS described in the
original documentation below, there were several problems, mostly
related to the assumption of 16 bit integers. This was taken care of
by a liberal dose of 'and'ing numbers with 65535. The problems caused
by octal constants ("10000)  and Radix-50 constants was easily taken
care of with machine translation. The bitwise functions were all
rewritten as actual function calls to functions whose names begins
with "Z". All the data that went into commons is now done through
block data subprograms or ordinary code.


Installation is moderately simple. First, you MUST edit the textcnv.f
and machdev.f files (umless you are using Microsoft Fortran on an IBM
PC.) You MUST get the proper bitwise functions and proper recordsize for
the dtext.dat file. This latter is the smallest recordsize that will hold
78 bytes. This goes in both textcnv.f and machdev.f. You must also, in
machdev.f, install the proper unit numbers your computer uses for terminal
read and write. It would be good to get time and date functions also, but
these are nonessential: if you can't get one or the other, just set all the
date values to 1 and put fixed numbers in the time values. Finally, you have
to, sigh, get a format for reading from your terminal, hopefully leaving the
user's reply on the same line as the prompt. Some systems simply
can't do this: on them, just try replacing the string ",$" with two spaces.

On Unix, all the .dat files need to be made all upper-case.

On some systems you must rename the .f files to .for.

Then compile and link textcnv.f, and run it. You'll get the
direct access file DTEXT.DAT.

Then compile and link all the other .f files to create the main
game program, which you should probably call Dungeon or Dungeon.exe.

If you don't have a Fortran compiler - the "f2c" converter works
just fine. Just run everything through f2c and then do to the .c
files what you would do to the .f ones. You might have problems with
overlapping libraries: read the f2c documentation.

Then play the game.

This version almost certainly will need some major changes on ones complement
computers, and very minor ones on non-ASCII ones, perhaps but not necessarily
including Primes. It should run on 16 bit computers. It does on the IBM-PC
with Microsoft Fortran and the 16-bit switch. On other 16 bit machines you\
might have to fix up a some constants that are greater than +32767.


******************************************************************************

The following is part of the text that came with the original DECUS
version of Dungeon. Instructions for putting it onto specific DEC
systems has been removed, as it was obsolete (and might have caused
terminal giggles.)

******************************************************************************

To:    Dungeon Players
From:    "The Translator"
Subj:    Game Information
Date:    8-OCT-80


This is the first (and last) source release of the PDP-11 version of
Dungeon.

Please note that Dungeon has been superceded by the game ZORK(tm).
The following is an extract from the new product announcement for
ZORK in the September, 1980 issue of the RT-11 SIG newsletter:

  "'ZORK:  The Great Underground Empire - Part I' ...was developed
   by the original authors based on their ZORK (Dungeon) game for
   the PDP-10.  It features a greatly improved parser;  command
   input and transcript output files;  SAVEs to any device and
   file name;  and adaptation to different terminal types,
   including a status line on VT100s.  Note:  this is not the
   FORTRAN version that has been available through DECUS.  This
   version has been completely rewritten to run efficiently on
   small machines - up to 10 times as fast as the DECUS version.

   ...ZORK runs under RT-ll, HT-ll, or RSTS/E and requires as
   little as 20K words of memory and a single floppy disk drive.
   The game package, consisting of an RX01-format diskette and
   an instruction booklet, is available from Infocom, Inc.,
   P.O. Box 120, Kendall Station, Cambridge, Ma. 02142."

ZORK(tm) is a trademark of Infocom, Inc.  It is available for several
popular personal computers as well as for the PDP-ll.


6.  Warnings and Restrictions

For those familiar with the MDL version of the game on the ARPAnet,
the following is a list of the major incompatabilties:

    -The first six letters of a word are considered
     significant, instead of the first five.
    -The syntax for TELL, ANSWER, and INCANT is different.
    -Compound objects are not recognized.
    -Compound commands can be delimited with comma as well
     as period.

Also, the palantir, brochure, and dead man problems are not
implemented.


7.  Abstract of Informational Printouts

SUMMARY
-------

            Welcome to Dungeon!

   Dungeon is a game of adventure, danger, and low cunning.  In it
you will explore some of the most amazing territory ever seen by mortal
man.  Hardened adventurers have run screaming from the terrors contained
within.

   In Dungeon, the intrepid explorer delves into the forgotten secrets
of a lost labyrinth deep in the bowels of the earth, searching for
vast treasures long hidden from prying eyes, treasures guarded by
fearsome monsters and diabolical traps!

   No DECsystem should be without one!

   Dungeon was created at the Programming Technology Division of the MIT
Laboratory for Computer Science by Tim Anderson, Marc Blank, Bruce
Daniels, and Dave Lebling.  It was inspired by the Adventure game of
Crowther and Woods, and the Dungeons and Dragons game of Gygax
and Arneson.  The original version was written in MDL (alias MUDDLE).
The current version was translated from MDL into FORTRAN IV by
a somewhat paranoid DEC engineer who prefers to remain anonymous.

   On-line information may be obtained with the commands HELP and INFO.
INFO
----

Welcome to Dungeon!

   You are near a large dungeon, which is reputed to contain vast
quantities of treasure.   Naturally, you wish to acquire some of it.
In order to do so, you must of course remove it from the dungeon.  To
receive full credit for it, you must deposit it safely in the trophy
case in the living room of the house.

   In addition to valuables, the dungeon contains various objects
which may or may not be useful in your attempt to get rich.  You may
need sources of light, since dungeons are often dark, and weapons,
since dungeons often have unfriendly things wandering about.  Reading
material is scattered around the dungeon as well;  some of it
is rumored to be useful.

   To determine how successful you have been, a score is kept.
When you find a valuable object and pick it up, you receive a
certain number of points, which depends on the difficulty of finding
the object.  You receive extra points for transporting the treasure
safely to the living room and placing it in the trophy case.  In
addition, some particularly interesting rooms have a value associated
with visiting them.  The only penalty is for getting yourself killed,
which you may do only twice.

   Of special note is a thief (always carrying a large bag) who
likes to wander around in the dungeon (he has never been seen by the
light of day).  He likes to take things.  Since he steals for pleasure
rather than profit and is somewhat sadistic, he only takes things which
you have seen.  Although he prefers valuables, sometimes in his haste
he may take something which is worthless.  From time to time, he examines
his take and discards objects which he doesn't like.  He may occas-
ionally stop in a room you are visiting, but more often he just wanders
through and rips you off (he is a skilled pickpocket).

HELP
----

Useful commands:

   The 'BRIEF' command suppresses printing of long room descriptions
for rooms which have been visited.  The 'SUPERBRIEF' command suppresses
printing of long room descriptions for all rooms.  The 'VERBOSE'
command restores long descriptions.
   The 'INFO' command prints information which might give some idea
of what the game is about.
   The 'QUIT' command prints your score and asks whether you wish
to continue playing.
   The 'SAVE' command saves the state of the game for later continuation.
   The 'RESTORE' command restores a saved game.
   The 'INVENTORY' command lists the objects in your possession.
   The 'LOOK' command prints a description of your surroundings.
   The 'SCORE' command prints your current score and ranking.
   The 'TIME' command tells you how long you have been playing.
   The 'DIAGNOSE' command reports on your injuries, if any.
Command abbreviations:

   The 'INVENTORY' command may be abbreviated 'I'.
   The 'LOOK' command may be abbreviated 'L'.
   The 'QUIT' command may be abbreviated 'Q'.

Containment:

   Some objects can contain other objects.  Many such containers can
be opened and closed.  The rest are always open.   They may or may
not be transparent.  For you to access (e.g., take) an object
which is in a container, the container must be open.  For you
to see such an object, the container must be either open or
transparent.  Containers have a capacity, and objects have sizes;
the number of objects which will fit therefore depends on their
sizes.  You may put any object you have access to (it need not be
in your hands) into any other object.  At some point, the program
will attempt to pick it up if you don't already have it, which
process may fail if you're carrying too much.  Although containers
can contain other containers, the program doesn't access more than
one level down.

Fighting:

   Occupants of the dungeon will, as a rule, fight back when
attacked.  In some cases, they may attack even if unprovoked.
Useful verbs here are 'ATTACK <villain> WITH <weapon>', 'KILL',
etc.  Knife-throwing may or may not be useful.  You have a
fighting strength which varies with time.  Being in a fight,
getting killed, and being injured all lower this strength.
Strength is regained with time.  Thus, it is not a good idea to
fight someone immediately after being killed.  Other details
should become apparent after a few melees or deaths.

Command parser:

   A command is one line of text terminated by a carriage return.
For reasons of simplicity, all words are distinguished by their
first six letters.  All others are ignored.  For example, typing
'DISASSEMBLE THE ENCYCLOPEDIA' is not only meaningless, it also
creates excess effort for your fingers.  Note that this trunca-
tion may produce ambiguities in the intepretation of longer words.

   You are dealing with a fairly stupid parser, which understands
the following types of things--

   Actions:
    Among the more obvious of these, such as TAKE, PUT, DROP, etc.
    Fairly general forms of these may be used, such as PICK UP,
    PUT DOWN, etc.

   Directions:
    NORTH, SOUTH, UP, DOWN, etc. and their various abbreviations.
    Other more obscure directions (LAND, CROSS) are appropriate in
    only certain situations.
   Objects:
    Most objects have names and can be referenced by them.

   Adjectives:
    Some adjectives are understood and required when there are
    two objects which can be referenced with the same 'name' (e.g.,
    DOORs, BUTTONs).

   Prepositions:
    It may be necessary in some cases to include prepositions, but
    the parser attempts to handle cases which aren't ambiguous
    without.  Thus 'GIVE CAR TO DEMON' will work, as will 'GIVE DEMON
    CAR'.  'GIVE CAR DEMON' probably won't do anything interesting.
    When a preposition is used, it should be appropriate;  'GIVE CAR
    WITH DEMON' won't parse.

   Sentences:
    The parser understands a reasonable number of syntactic construc-
    tions.  In particular, multiple commands (separated by commas)
    can be placed on the same line.

   Ambiguity:
    The parser tries to be clever about what to do in the case of
    actions which require objects that are not explicitly specified.
    If there is only one possible object, the parser will assume
    that it should be used.  Otherwise, the parser will ask.
    Most questions asked by the parser can be answered.
8.  Source Notes

A few notes for source hackers.

******************************************************************
*                                                                *
*   [ This has been superceded for Dungeon 1990 version.]        *
*                                                                *
******************************************************************

- The initialization module (DINIT.FTN) includes an access protection
  function PROTCT.  If PROTCT returns a value of .TRUE., the game is
  permitted to start;  if PROTCT returns .FALSE., the game is
  terminated with a suitably nasty message.  At present, PROTCT is a
  dummy routine and always returns .TRUE.;  by tailoring PROTCT,
  access to the game can be restricted to certain hours or users.

- The data base OPEN and READ statements are in the initialization
  module (DINIT.FTN).  The data base file names are simply "DINDX.DAT"
  and "DTEXT.DAT".  These may be freely changed to include logical
  device names, UIC's, etc.  Thus, it is possible to place the data
  base files on different devices, in a fixed UIC, etc.

- Converting the game to another processor is not a straightforward
  procedure.  The game makes heavy use of extended and/or
  idiosynchratic features of PDP-11 Fortran.  Particular nasties
  include the following:

  > The game vocabulary is stored in Radix-50 notation.

  > The game uses the extended I/O commands OPEN and CLOSE.

  > The game uses LOGICAL*1 variables for character strings.

  > The game uses logical operators on integers for bitwise binary
    operations.

  > The game treats certain arrays and variables as unsigned
    16-bit integers (integer overflow may occur).

  In general, the game was implemented to fit in memory, not to be
  transported.  You're on your own, friend!